verify-deployment --allow-unlocked, and both lockfiles regenerated on bun 1.4.0 - #12

No behaviour change, and nothing to migrate in the dApp. bun run verify:deployment with no arguments does exactly what it did before; the contract, src/managed/ and every served artifact are untouched (a full compact compile +0.31.1 still reproduces src/managed byte for byte); and every version this repo pins is on the same version it was on before. What lands is an opt-in CLI flag with 17 unit tests and docs, plus three defensive overrides and a regeneration of both lockfiles.

⚠️ One consumer-visible requirement: the minimum bun for this repository is now 1.4.x. bun 1.4 writes "lockfileVersion": 2 and has no flag to write the old format, and bun 1.3.x cannot read it (error: Unknown lockfile version). This workflow's oven-sh/setup-bun@v2 is unpinned and already installs 1.4.0, so CI is unaffected — but anything that installs this tree with an older bun must move to a 1.4.x base at the same time it pins a commit from this branch. Concretely: both demo stacks' images/shielded-night/Dockerfile pin oven/bun:1.3.11 by digest and run bun install --frozen-lockfile in both trees; their SHIELDED_NIGHT_REF re-pin commit has to bump BUN_BASE too. Measured below.

This PR carries both halves of the follow-up: the --allow-unlocked flag, and the lockfile regeneration that was previously held pending a decision on whether package.json could be touched (it could — see §2).

1. --allow-unlocked for scripts/verify-deployment.ts

verify-deployment.ts asserts two things and exits 0 only if both hold:

1. CODE — every on-chain verifier key is byte-identical to src/managed/keys/*.verifier, and the circuit sets match exactly.
2. LOCK — the maintenance authority is dissolved, so no rule can ever change.

That is right for a hosted release. It is wrong for a devnet: a demo stack deliberately leaves the contract unlocked (SHIELDED_NIGHT_LOCK=false), because locking is a one-way door and a throwaway contract gains nothing from it.

The consequence, measured against the live preprod contract e354e6725893397e6a2dfa44522a017fabb5d9c92efed50288711f5f865c8950: the script prints eleven ✓ lines and then exits 1. So the strongest check a demo stack can run is unreadable from its exit code — which is exactly how both demo stacks consume it, as the exit status of a compose one-shot rather than as parsed stdout.

--allow-unlocked keeps measuring and printing the lock state, but lets only the code check decide the exit code.

# strict (hosted release) — unchanged
MN_ENV=preprod CV_ADDRESS=<addr> bun run verify:deployment

# devnet gate — lock state reported, exit code = the verifier-key check only
MN_ENV=undeployed CV_ADDRESS=<addr> bun run verify:deployment -- --allow-unlocked

The flag only ever changes what an unlocked contract does to the exit code. It never weakens the code check. Unknown arguments are rejected rather than ignored, so a typo (--allow-unlock) fails loudly instead of silently reverting to strict behaviour and reading as "the flag does not work".

Shape

The policy is extracted into a new dependency-free scripts/verify-args.ts (parseVerifyArgs, verifyOutcome, lockVerdictLine) — the same seam pattern as scripts/deploy-record.ts. verify-deployment.ts keeps all the chain work and just calls it. That makes the exit-code table unit-testable with no chain, no docker and no new dependency.

How it was verified

bun run test:unit → 95 passed / 95 (7 files; was 78/78 in 6 — 17 new). bun run typecheck exit 0.

Measured against the live preprod contract above (unlocked: committee=1 threshold=1 counter=0; keys match), read-only, no wallet or seed:

Row 3 is the one that matters: the flag does not weaken the key check.

Docs

• README.md → new subsection under "Verifying the deployment": what it relaxes, what it never relaxes, sample output, why not to use it for a hosted release.
• TESTING.md → "Verifying a deployment as a gate", with the exit-code table and a pointer to the unit test.

2. Lockfile regeneration on bun 1.4.0, with three pinning overrides

CI installs with an unpinned oven-sh/setup-bun@v2, so it now runs bun 1.4.0, while both lockfiles here were written by an older bun. The plan was to delete them and regenerate wholesale on 1.4.x with package.json untouched. Measured with oven/bun:1.4 = bun 1.4.0+34cbb9a40 (the newest release, i.e. exactly what CI installs) against a git archive of main @ 6d87db4, that is not possible — two independent defects surface, both in the family this repo pins on purpose.

Defect 1 — the root tree does not install at all

error: No version matching "^0.1.0-alpha.1" found for specifier "@midnight-ntwrk/ledger-v9" (but package exists)
error: @midnight-ntwrk/ledger-v9@^0.1.0-alpha.1 failed to resolve

The root declares "@midnight-ntwrk/compact-js": "^2.5.1" — the only loose range in the midnight family. compact-js has since published 2.5.3 (now dist-tags.latest), and 2.5.3 replaced its ledger-v8: ^8.0.3 dependency with ledger-v9: ^0.1.0-alpha.1, a range that is no longer published (the v9 line moved to 1.0.0-rc.x). The committed lockfile hid this by pinning 2.5.1; deleting it exposed it.

This is a pre-existing landmine on main, not something this branch introduces: a plain bun install at the repo root fails today, so only --frozen-lockfile is safe. And even if 2.5.3 did resolve, taking it would put two copies of compact-js in the tree (2.5.3 direct, plus the 2.5.1 that midnight-js-protocol@4.1.1 pins exactly) — the exact class-identity hazard the //overrides note was written about.

Defect 2 — both trees fork the onchain-runtime WASM

With package.json untouched, frontend/ does regenerate (271 packages) with every pinned version intact — but @midnight-ntwrk/onchain-runtime-v3 goes from one copy to two, in both trees: 3.1.0 hoisted plus 3.0.0 nested under midnight-js-protocol@4.1.1, which pins it exactly while compact-runtime@0.16.0 asks for ^3.0.0 (now satisfied by the newly published 3.1.0).

onchain-runtime-v3 is named in frontend/vite.config.ts's resolve.dedupe for precisely this reason — its comment reads that two WASM instances give classes that "fail each other's instanceof checks ("expected instance of ChargedState" when reading ledger state)". On the frontend dedupe would paper over it, but only by silently substituting 3.1.0 where midnight-js-protocol pinned 3.0.0. On the root/Node side — the integration suite, deploy.ts, verify-deployment.ts — there is no dedupe, so both copies genuinely load.

The fix: three overrides

// package.json
"overrides": {
  "@midnight-ntwrk/compact-js": "2.5.1",          // NEW
  "@midnight-ntwrk/ledger-v8": "8.1.0",
  "@midnight-ntwrk/onchain-runtime-v3": "3.0.0"   // NEW
}
// frontend/package.json
"overrides": {
  "@midnight-ntwrk/compact-js": "2.5.1",
  "@midnight-ntwrk/compact-runtime": "0.16.0",
  "@midnight-ntwrk/ledger-v8": "8.1.0",
  "@midnight-ntwrk/onchain-runtime-v3": "3.0.0"   // NEW
}

Neither override forces a version below anybody's floor. In both regenerated lockfiles every requirement for compact-js is either the exact 2.5.1 that midnight-js-protocol@4.1.1 pins or the root's own ^2.5.1, and every requirement for onchain-runtime-v3 is either the exact 3.0.0 that midnight-js-protocol@4.1.1 pins or compact-runtime@0.16.0's ^3.0.0 — the pins satisfy all of them, and simply pick one of several admissible resolutions.

They are the same defensive pin the file already applies to ledger-v8, and the top-level //overrides note is rewritten to say, per entry, which class identity it protects and why the pin is needed — so the next person does not have to re-derive it from an npm graph.

Nothing that must hold, moved

Every other @midnight-ntwrk/* / @midnightntwrk/* change, in full

No @effectstream/* package exists in either tree.

Ordinary tooling drift

Root: 76 names changed, 1 added, 8 removed (376 → 369 distinct names). Frontend: 54 changed, 1 added, 1 removed (315 → 315).

The root removals are all wasm-fallback binding packages that rolldown 1.2.7 no longer pulls (@rolldown/binding-wasm32-wasi, @emnapi/*, @napi-rs/wasm-runtime, @tybys/wasm-util, bare-os, is-what), replaced by @rolldown/binding-android-arm-eabi. @types/node at the root goes from one copy to three (24.13.3 plus 18.19.130 and 26.4.1 nested under @types/ssh2 / undici-types); bun run typecheck is green with it.

How it was verified

Every run used bun 1.4.0+34cbb9a40 in a short-lived oven/bun:1.4 container over a git archive export of this branch.

The bun floor, measured

bun install --help on 1.4.0 offers --save-text-lockfile and --lockfile-only and nothing that selects a lockfile version, so the bump is unavoidable once the lockfiles are regenerated on 1.4. Hence the warning at the top of this PR.

Follow-ups this unblocks

• Both demo stacks' verify sections can drop their stdout parse and read the exit code instead (midnight-1-offers scripts/verify-shielded-night.sh via docker compose run --rm shielded-night-verify, and its midnight-2-offers counterpart).
• A plain bun install at the root works again for the first time since compact-js 2.5.3 was published, so adding a dependency no longer requires reverse-engineering an npm graph.
• Both of those re-pins happen in the demo repos, not here — and each must bump BUN_BASE from oven/bun:1.3.11 to a 1.4.x digest in the same commit.